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ABSTRACT 



The Administrative Sciences (AS) Department of the Naval 
Postgraduate School (NPS) maintains a large amount of plant 
and minor property to support its vast and varied operations. 
This property requires accurate record keeping to assure 
accountability of each item throughout its lifetime, from 
initial acquisition through disposal. The AS Department 
implemented a Financial Management Information System (FMIS), 
through the work of prior NPS students, at the commencement of 
FY 91. This thesis develops and integrates the Property 
Management Module into the FMIS to support the management and 
accountability of the AS Department property. The new 
expanded version is named FMIS 2.0. An outline covering 
software maintenance analysis, the Property Management system 
requirements analysis, and system design methodology is 
provided. The system was written using dBASE IV, version 1.1 
and will transition to operational status from the current 
FMIS at the beginning of FY 92. 
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I. INTRODUCTION 



A. BACKGROUND 

The need for a computerized data base system for the 
Administrative Sciences (AS) Department of the Naval 
Postgraduate School (NPS) has been an ongoing subject of 
thesis study by several previous NPS students. A basic 
requirement for the system is to process related resource data 
in four functional areas: Personnel, Property, Supply, and 
Travel. The prior theses [Ref. 1,2, 3, 4] varied in their 
approaches toward developing a system and culminated in the FY 
91 implementation and use of the first version of the 
Financial Management Information System (FMIS) developed by 
Neil Ford and Nicholas Zimmon [Ref. 4]. 

This initial version of the FMIS, developed using dBASE 
IV, has proven operationally satisfactory . However, it did 
not include a property management module which is required to 
track plant and minor property during its lifetime in the AS 
department. The requirement for this property module was 
recognized during development of the initial system and was 
planned to be incorporated as a software maintenance 
enhancement update through follow-on thesis work. This thesis 
accomplishes that work and includes a brief overview of soft- 
ware maintenance and the database application development 
process . 
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B. FMIS VERSION 2.0 



The major change to the FMIS in developing the second 
version is the integration of a property management system 
module into the original application. To effectively 
assimilate the enhancement, the system architecture developed 
for the initial system was followed as closely as possible. 
This required close attention to detail during the 
requirement, evaluation, and design phases of the application 
development. This ensures that the property management sub- 
system when completed, could be incorporated into the FMIS. 
It was crucial to ensure that the common fields needed to link 
the relations between objects were identical in structure. 
For these reasons this thesis study does not explore new 
software tools, instead it concentrates on expanding the 
existing arch i tecture . 

The system was developed using Ashton-Tate ’ s dBASE 4, 
version 1.1. After extensive personal interviews with the 
departmental staff, a prototype system was rapidly developed 
and presented for critique by all expected users. The final 
property module system incorporated functional and data 
requirement changes identified during prototype testing. It 
required programmer coding with the dBASE programming language 
to obtain the advanced features required of the system as well 
as procedures required for the successful integration with the 
original FMIS. 
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The Property Management sub-system provides new record 
entry for various fields as illustrated in Appendix E. It 
also provides retr i eval of specific records for editing, 
deletion of records, and selection of the following property 
reports : 

1 . Property Custody Log 

2. Property Disposal Report 

3. Property Custody History Report 

4. Minor Property Inventory Report 

5. Plant Property Inventory Report 

6. Property Location Report 

In addition to its original functions, FMIS version 2,0 
now provides an accurate, user-f riendly , and efficient means 
of tracking accountable property custodianship throughout the 
Administrative Sciences Department. 

C. CHAPTER DESCRIPTION 

Chapter II reviews basic fundamentals of software 
maintenance. Operating in a dynamic environment, software 
must continually be modified in order to perform its required 
function to meet user satisfaction. These changes can often 
exceed the effort required to develop the initial system. The 
type of maintenance in developing FMIS 2.0 will be examined. 

Chapter III will review the database application 
development methodology and outline the methods as used in 
developing the Property Management Sub-system (PMS). The def- 
inition, requi rements , evaluation, design, and implementation 
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phases will be covered. The soundness of the new property 
database relation structure as to which level of normal form 
it satisfies will be discussed. 

A description of all new reports generated by the PMS in 
FMIS 2.0 will be laid out in chapter IV. 

Chapter V, Conclusions, discusses usability of the system 
and areas for further development. There may be enough 
perfective maintenance to warrant further changes, possibly as 
study for another thesis study. 

Appendices A through E include sections on requirements 
documentation, data dictionary, custom programming procedures, 
application documentation, and a user’s guide. 
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SOFTWARE MAINTENANCE 



II . 



Development of the Property Management sub-system and its 
subsequent integration into the FMIS program falls under the 
classification of software maintenance. Maintenance requires 
a different approach towards development as well as present- 
ing a different set of problems than those that would be 
encountered when developing an initial system. 

A. MAINTENANCE EFFORT REQUIRED 

In contrast to the "finished" product of an initial 
software (s/w) system, maintenance of that system is an 
ongoing concern. This maintenance effort can easily exceed 
the entire effort expended on the original project, often 
exceeding over 60 percent of the total effort exerted on the 
system throughout its life. Why is there a need for so much 
maintenance? Rochkind [Ref. 5] provides some insight: 

Computer programs are always changing. There are bugs to 
fix, enhancements to add, and optimizations to make. 
There is not only the current version to change, but also 
last year’s version (which is still supported) and next 
year’s version (which almost runs). Besides the problems 
whose solutions required the changes in the first place, 
the fact of the changes themselves creates additional 
problems . 

The reason that maintenance is a consistent ongoing effort is 
that the users are usually never completely satisfied with the 
product they are using. Additional desired or required 
features are needed to make the system perform as wanted. 
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One of the many factors increasing the complexity of s/w 
maintenance is the turnover of personnel involved in the 
development of the original system. The time required of the 
new maintenance programmers to learn the system (the learning 
curve) is a factor that cannot be underestimated nor over- 
looked. With all factors considered, changes are often more 
complex to execute than might appear. The changes 
incorporated in developing FMIS 2.0 could have been accom- 
plished in considerably less time by the original developers 
(Ford and Zimmon). The study of code and documentation took 
approximately a third of the entire maintenance time for the 
system enhancement . The complete maintenance effort distribu- 
tion in development of FMIS 2.0 is shown in Figure 2.1. This 
large percentage of the total effort emphasizes the need for 
highly accurate and complete system documentation to aid 
future maintenance efforts. 



TESTING 




Figure 2.1 FMIS 2.0 Maintenance Effort Distribution 
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Ensuring a complete software configuration in the original 
development allows a structured maintenance approach. This is 
much more efficient than performing unstructured maintenance 
(maintenance from scratch) which causes a high degree of 
wasted effort and human frustration. Use of standard dBASE IV 
configuration (through use of the dBASE control center) in the 
majority of the initial development provided a sufficient 
framework for a structured maintenance approach in the 
upgrade, see Figure 2.2. The only unstructured items to be 
analyzed were original programming code procedures in the 
ACCTSPROC . PRG file (see Appendix C) used in the original FMIS. 




Figure 2.2 Structured Maintenance Approach 
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B. TYPES OF SOFTWARE MAINTENANCE 



There are three major categories of software maintenance 
as outlined below. Although each type is often i nterrel ated , 
requiring accomplishment at some or many points during the 
system lifecycle, each specific maintenance function can 
easily be categorized. 

1. Corrective Maintenance 

Corrective Maintenance is the effort involved in 
correcting errors after initial system delivery. It is 
practically impossible to discover all errors during system 
testing. When they eventually occur during system use, they 
should be recorded by the users and reported to whoever is 
tasked with maintaining the s/w. The errors must then be 
diagnosed and corrected. Corrective maintenance usually takes 
up about 20 percent of the total maintenance effort. No 
corrective type maintenance was performed on the original 
system in the development of the new FMIS. 

2. Perfective Maintenance 

Requiring approximately 10 percent of total main- 
tenance effort, perfective maintenance takes the least amount 
of programmer attention of the three major categories. This 
term applies to maintenance performed making improvements of 
the systems performance and/or quality through modification to 
existing functions (fine tuning). This is accomplished on 
systems that have already been proven operationally 
successful. An example of this might be the reformatting of 
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a report for better readability. About 10 percent of the FMIS 
2.0 development was perfective maintenance to the original 
FMIS. 

3. Software Update Maintenance 

Update maintenance accounts for the largest chunk of 
the total maintenance effort, approximately 70 percent. It is 
divided into two sub-categories as described below. 

a. Adaptive Update 

This is the work required to modify software to 
properly interface with an operating environment that may 
undergo a variety of change. The changing environment may 
constitute hardware or software reformation. Examples could 
be either the introduction of a new operating system or 
hardware upgrades. Adaptive maintenance was not required for 
the FMIS. 

b. Enhancement Update 

Enhancements account for about two-thirds of all 
updates and 45 percent of total maintenance. As successful 
software is used, requirements for new capabilities beyond the 
scope of the original system are discovered. Enhancements 
usually consist of new functional modules to be developed and 
integrated to the original code. 

The Property Management sub-system enhancement 
accounts for almost all of the work in developing FMIS 2.0. 
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Ill . 



DATABASE APPLICATION DEVELOPMENT 



The five phases utilized in the development of the FMIS 
enhancement will be discussed in this section. Each phase 
methodology will be discussed followed by how that phase was 
applied in generating the Property Management sub-system. 

A. PHASE I, DEFINITION PHASE 

1 . Methodology 

The definition phase includes preliminary activities 
with a major goal of simply finding out what needs to be done. 
The development team must be formed, scope of the project 
established, and feasibility (cost, technical, and schedule) 
assessed. This is the simplest phase in the development 
process . 

2. Application 

The goal of this project was to develop a Property 
Management system and integrate it as an enhancement into the 
FMIS currently in use in the A.S. department office. It was 
decided that the scope of this work warranted development as 
an individual thesis project. All feasibility items were met 
satisfactorily. Work would be performed on a 386, 25 Mhz IBM 
compatible PC owned by the thesis student. This resulted in 
negligible cost factors. A time span of eight months with 
commencement in January 1991 and system completion by August 
1991 was considered feasible. Phase I was accomplished during 
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a single interview with Professors Tung Bui and Shu Liao that 
took approximately one hour. 

B. PHASE II, REQUIREMENTS PHASE 

1 . Methodology 

Identifying the objectives of the proposed system in 
detail is the goal of the requirements phase. Requirements 
are the blueprint that will be used to design and implement 
the new system. Before being able to move on to development, 
the developer must know exactly what the system is supposed to 
do. It is not only important that the system is built 
correctly, but vital that the right system is built. Proper 
definition of the requirements can prevent future maintenance 
nightmares . 

There are two major tasks in defining database 
requi rements . The first is to identify the objects. Objects 
are a collection of properties which depict an item to be 
implemented in the database. An object instance is an example 
of a specific object. The second step is to determine what 
functions each application will perform in the database. 
These requirements are most effectively identified by 
conducting a series of interviews with the expected users. 
After initial interviews a prototype may be built and 
demonstrated to receive further user design input. 

2. Application 

Interviews commenced the first week of February 1991 
with the three expected users of the system: Chan Burns- 



research technician, Jan Evans-administrative officer, and 
Pearl Murray-Suppl y clerk. A factor to remember when planning 
interviews during this phase is that interviewees typically 
will have full time job duties and schedule interruptions must 
be expected. Group interviews were beneficial to minimize 
receipt of conflicting data requirements from the various 
users . 

The initial interviews lasted approximately two and a half 
weeks. Working with initial data requi rements , a prototype 
Property Management System (PMS) application with sample input 
screen and reports was developed and presented to the users 
for review on March 27, 1991. Several changes to the initial 

requirements were requested by the users and the prototype was 
reworked with these changes. This cycle was repeated several 
times over the next two months. Fortunately the time schedule 
for delivery of the final product had ample flexibility 
permitting these constant changes, 
a. Data Requirements 

The PROPERTY object, as determined through the 
interview/prototype process is shown in the Object Diagram, 
Table 1, Appendix A. This single new object was the only one 
required for the system enhancement. All properties of the 
object listed in the diagram represent an important 
character i sti c of department property items to be tracked. 
The Personnel property is an object property , which means that 
this entity character i sti c is actually another object. The 



PERSONNEL object developed in the first FMIS [Ref. 4] will 
contain properties of the person for whom the department 
property is assigned custodianship. Additional PROPERTY 
object data information is supplied in Appendix A, Tables 2 
and 3. Table 2 provides the Object definition which lists all 
of the objects properties and each properties domain. Table 
3 is the Domain definition which specifies formats of each 
domain. This information is used for the database design in 
Phase IV. 

b. Application Functional Requirements 

In order to track departmental property items 
assigned to various custodians, a property clerk must assign 
a unique tag number to each individual item to be entered into 
the system. This tag number will identify that particular 
piece of property entered in the database. Functions required 
by the PMS were patterned after the existing applications 
already incorporated into the FMIS. These functions include 
record entry, display, editing, deletion, and report 
generation . 

The data flow diagram (DFD), Figure 3.1, shows a 
graphic model of the PMS system to be used as an aid in 
design. The DFD is comprised of four elements: the data flow, 
represented by an arrow; the process, represented by a circle; 
the data store, represented by an open ended rectangle; and 
the source/sink, which is shown as a closed box. 



Tagge d 

Properly Item 



PROPERTY 

CUSTODIAN 




Figure 3.1 Data Flow Diagram 
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Property items to be tagged and assigned to a 
staff or faculty member for custodianship are received by the 
property clerk. Each item ordered under a document number. 
However, this number cannot be used as a unique identifier 
since several property items may have been ordered under the 
same document number. The tag numbers are used as unique 
property identification. Only one tag number will be assigned 
to any one item. Tag numbers are not in strict sequence and 
may occasionally change depending on the current stock of 
available tags. Sequences can also vary between minor and 
plant property. 

As shown in Figure 3.1, the ENTER NEW RECORD 
process requires the input of new property information data 
along with the custodian’s Personnel ID. The process will 
validate the personnel ID with the PERSONNEL database and 
retrieve the new custodian’s first and last names. The 
process will not enter a new record with an invalid personnel 
ID (IDs that do not exist in the PERSONNEL records). The 
newly assigned property info data record will be stored in the 
PROPERTY data file. 

The EDIT RECORD process requires the entry of a 
valid tag number. This process searches the PROPERTY data 
file and retrieves that property record for manipulation or 
deletion. The edited record will then be stored in the file 
replacing the original record. 
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A final process is required to produce the desired 
reports. Upon receiving a report request, the PRINT REPORTS 
process will retrieve relevant report data from the PROPERTY 
and PERSONNEL data files and generate the report. Table 4 
and 5, Appendix A, summarize the update and display mechanism 
requirements for the PROPERTY object. 

C. PHASE III, EVALUATION 
1. Methodology 

Using the information gathered during the requirements 
phase, this development stage typically consists of an 
evaluation of several items of concern to the developer and 
customer . 

First is the identification of alternative application 
system archi tectures . The question needs to be asked, "Are 
there other system architectures that would better serve our 
needs than the one we are planning to use?" Determining the 
availability of the alternative architecture also needs to be 
done. Quite often an organization cannot afford the most 
efficient, state of the art technology. 

Another concern that must be evaluated is the feas- 
ibility of the project. Can it actually be developed? The 
detail of the completed requirements may provide insight that 
preclude further development. Additional time and resources 
should not be spent on a system that will never be completed. 
Several large corporat i ons , as well as the government, have 
abandoned development of poorly evaluated systems after 
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investing tens of millions of dollars. Careful evaluation of 
the requirements may prevent this from occurring. 

A final area of appraisal is the scope of the project. 
Given the stated time constraints for final delivery, can all 
functional areas laid out in the requirements be developed? 
Priorities must be determined and some requirements may need 
to be postponed and developed at a later date. 

2. Application 

The Evaluation Phase was simplified by constraints 
that contribute to the pre-determination of the required 
architecture as well as a good understanding of the expected 
requirements during the Definition Phase. As an enhancement 
to an existing program, it was decided that the new Property 
Management module would be developed using the same software 
package (dBASE IV) for ease of integration into the FMIS 
application. Another factor was the availability of dBASE IV 
tools on a large number of computers at NPS. The hardware 
platform was not a consideration either. The system would be 
run on the AS department office’s IBM compatible PC (Northgate 
386) . 

Using the structured maintenance approach it was clear 
that the planned system upgrade could be accomplished. 
Feasibility was not a problem. It was evaluated that all 
requirements as documented in the requirements phase could be 
completed and delivered on time. This was determined by 
examining the scope of the original FMIS project (a joint 



project of two NPS students) and estimating the time required 
for a single student to perform the less extensive enhancement 
upgrade. One undocumented requirement that needs to be 
performed at a later date (possible follow-on thesis work) is 
the development of a security system for the FMIS. A password 
type system is desired to prevent unauthorized users from 
gaining access to all FMIS database files. 

D. PHASE IV, DESIGN PHASE 

1. Logical Database Design 

In logical database design, the initial information 
laid out during the requirements phase will be developed into 
a set of plans for the database structure. Logical database 
design is generic, specific design requirements for 
programming with dBASE IV will be covered by the Physical 
Database design procedure. The requirements determine what we 
want and the design determines how to accomplish those goals. 
Logical design plans developed from the object diagrams and 
object definitions consist of relation diagrams, relation 
definitions, and the constraints on the relations. 

The PROPERTY object was transformed into the PROPERTY 
relation as seen in Figure 3.2. The PROPERTY relation uses 
Property-tag-number (TAGNR) as its primary key. A key is an 
attribute that functionally determines the non-key attributes. 
The PROPERTY relation is related to the PERSONNEL relation in 
a one-to-many binary relationship. The "fork" at the PROPERTY 
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PERSONNEL 
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Code 
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Address 



\ 



PROPERTY 
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Property- tag 
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* Supply-document 




Number 


Code 


type 


number 






SUPPLY 



* Supply-document 








number 


Vendor 


Estimated - price 





* - indicates common field 

Figure 3.2 Property Relation Diagram 



end of the relationship line means that there are potentially 
many property items for each person in PERSONNEL. The 
abscense of a fork at the other end indicates that each 
property item can be assigned to at the most, one person at 
any one time. The circle on the line means that the 
relationship from PERSONNEL to PROPERTY is optional. A 
PERSONNEL member doesn’t have to have any property assigned to 
them. The bar on the line at the other end indicates that a 
PERSONNEL record must correspond to a PROPERTY record. 
PROPERTY is linked to SUPPLY in much the same manner. 

The relational database model is based on the concept 
that data is stored in two-dimensional tables referred to as 
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relations. Each row in the table represents a record. Each 
column represents a field. The entire table (relation) is 
what is roughly known as a file. A row is called a tuple and 
a column (field) is called an attri bute. [Ref . 6] 

The relational structure afforded by dBASE IV allows 
linking these separate data files through use of a common 
field. The common field linking PROPERTY and PERSONNEL 
relations is Personnel -ID-code (IDCODE). The common field 
linking PROPERTY to SUPPLY is the Supply-document-number 
(DOCNR). The database hierarchy, updated from the original 
design [Ref. 4:p. 9], incorporates the new PROPERTY relation 
as shown in Figure 3.3. 
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2. The Normalization Process 



When designing relations from object diagrams, careful 
attention to the normalization process must be observed to 
prevent building anomalies into the database structure. 
Anomalies are weaknesses and flaws in the relations that cause 
undesirable effects when modifying a database. Types of 
modification anomalies include deletion and insertion 
anomalies. Deletion anomalies refer to problems that occur 
when the deletion of facts from one relation entity inadver 
tently deletes facts about another entity. Insertion 
Anomalies describe the restriction of ability to insert 
information about one entity until additional facts are 
received about some other entity. Minimization of 

modification anomalies was of major concern when designing the 
PROPERTY relation. The "normalization process" is the method 
to identify and eliminate modification anomalies. Dividing a 
relation may be required to eliminate any discovered 
anomal i es . 

The normalization process consists of testing the 
relation along a series of normal forms. The term normal form 
refers to the class of relations and techniques for preventing 
anomalies. There are seven normal forms, the highest level 
being Domain/Key Normal Form (DK/NF). When a relation is in 
DK/NF it is guaranteed not to have any anomalies. A relation 
might fall in any of the normal forms depending on its 
structure. The normal forms are described below along with 
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the determination of which form requirements the PROPERTY 
relation satisfies. 

a. First Normal Form 

The only requirement of this normal form is that 
the relation has no repeating groups. The PROPERTY relation 
meets this requirement. 

b. Second Normal Form 

All non-key attributes must be dependent on all of 
the key. PROPERTY has a single attribute key ( Property-tag- 
number), therefore it is automatically in second normal form. 

c. Thi rd Norma 1 Form 

The relation must be in second normal form and 
have no transitive dependencies. No apparent transitive 
dependencies could be detected in PROPERTY so it meets this 
form requi rements . 

d. Boyce-Codd Norma 1 Form 

A relation is in this form if every determinant is 
a candidate key. However, PROPERTY does not make it past this 
normal form, a deletion anomaly still exists at this point. 
If a property item assignment record is removed from the file 
then the historical information as well as the property 
details are lost. An alternative approach would be to split 
the relation into separate PROPERTY-ASSIGNMENT, PROPERTY- 
DETAIL, and PROPERTY-HISTORY relations. This was not deemed 
necessary for the PMS system since once a property item is 
tagged and entered into the file the record should never be 
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deleted. The record is maintained even when the item is 
disposed. This will prevent the problem of the deletion 
anomaly from occurring. 

e. Fifth Normal Form 

No clear definition identifies this form, but it 
is known that even at this level obscure anomalies can occur. 
This led to the creation of the DK/NF. 

f. Domain/Key Normal Form 

As stated earlier, this is the final form. All 
possibility of relation modification anomalies have been 
removed. A relation is in the DK/NF if every constraint on 
the relation is a logical consequence of the definition of 
keys and domains [Ref. 6:p. 149]. 

3. Physical Database Design 

This stage of the design phase will transform the 
logical database design into a physical blueprint to meet 
specific data element patterns required for programming the 
application in the dBASE IV dbms. The logical PROPERTY 
relation attribute names will need to be changed to meet dBASE 
IV’s field name requirement to not exceed 10 characters. The 
field names must start with an alpha character, but can then 
be followed by numbers. The underscore (_) is the only non- 
alphanumeric character allowed in the name. Each field must 
also be categorized as one of six data types used in dBASE IV: 

1. Character - textual information 

2. Numeric - any true numeric value 
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3. Float - useful for numbers with no fixed number of 

decimal places. 

4. Date - date stored in the mm/dd/yy format 

5. Logical - contains either a true or false value 

6. Memo - large volumes of text (up to 64K) 

The total number of fields in the PROPERTY data file numbers 
59 (40 of these used for historical data) which easily meets 
dBASE IV’ s maximum limitation of 255 fields for any single 
database record. Table 6 in the Data Dictionary (Appendix B) 
lists all the PROPERTY data file elements in proper form. 

4. Property Management ( PMS ) Application Design 

An application is the collection of menus, forms, 
reports, and programs that perform the functions of the system 
required by the users. Before proceeding to the 

Implementation phase the final task is to design the 
application. Once the basic designs for the PMS were laid out 
on paper, a quick prototype was developed to demonstrate the 
menus, input form screen, and reports to the users. User 
requested modifications to the prototype were incorporated to 
form the final application design. 
a. Menu Design 

Since the development of the PMS system was to be 
an enhancement to the FMIS already in use, it was decided to 
follow the current structure in designing the PMS menus. This 
would allow easier program integration in the implementation 
phase and ease the user transition to the new system. The 
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menu hierarchy design is illustrated in Figure 3.4. Main menu 
options from the first FMIS version are shaded. The PROPERTY 
selection from the main menu produces a pop-up type menu with 
the selections as shown in the figure. The PRINT REPORTS 
selection from the pop-up menu produces a pull-down menu with 
the six various report options. A final pull-down menu (not 
illustrated) provides the user with choosing either the 
screen, LPT 1 , LPT2, or writing to a file as destination 
options for the chosen report. 




CUSTODIAN 

LOG 


DISPOSAL 

REPORT 


HISTORY 

REPORT 


LOCATION 

REPORT 


MINOR 

PROPERTY 

REPORT 


PLANT 

PROPERTY 

REPORT 









Figure 3.4 PMS Menu Hierarchy 
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b. Screen design 

Variations in the screen layout design can either 
ease or impede system use. Screen design begins with 
determination of the information and fields that will be 
placed the screen and then effectively designing the 
arrangement so that the data will fit within the screens 
physical limitations. 

The ENTER NEW RECORD and EDIT/VIEW RECORD form 
screens had to be laid out to meet dBASE IV’s physical 
application design requi rements . Custom forms in dBASE can be 
as wide as the screen, 80 columns. The number of rows, how- 
ever should be limited to 21 to allow room at the bottom of 
the screen for pop-up program messages. The screen design for 
the PMS involves a two page form. The first page consists of 
all current property and custodian information. The second 
page contains historical data fields. An entry screen should 
be designed to minimize the number of keystrokes required by 
the data entry operator. An efficient design saves entry time 
and is less frustrating to use. Keeping this in mind, all 
entries requiring eventual editing were placed at the top of 
the form. Information required for entry on the second page 
is automatically transmitted in flashing fields to allow the 
user to enter historical data without having to refer back to 
the first page. Another characteristic of good screen design 
is the varying use of colors. Fields requiring data entry are 
of a uniform color that is different from information only 
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fields (see Appendix E). This aids in easy identification of 
entry fields. Another design feature incorporated was the use 
of default field entry when possible. Several fields 
identified in the following paragraph automatically fill 
themselves with predetermi ned data. This data can be accepted 
as is, or changed by entering something new. 

Various features were desired of certain form 
screen fields. The following features were designed for the 
first form page. The TAG NUMBER field was designed to verify 
that the new number entered had not been previously used in 
another record. Validation of CUSTODIAN ID with IDs in the 
PERSONNEL database is required for the form to accept the 
entry. When a valid ID is entered, the individuals LAST NAME 
and FIRST NAME fields are automatically filled. Since the 
majority of AS department personnel utilize offices in 
Ingersoll Hall, a default entry of "I" is entered for the 
location room number. The DATE ASSIGNED entry field has a 
default setting of the current date, entered by the system. 
ADP CODE has a default entry of "0" for non-ADP property. A 
default of "M" (minor property) is entered for PROPERTY TYPE. 
The DISPOSED field gets an automatic value of "N" and also 
prevents any entry into the DISPOSAL DATE field until it is 
changed to " Y" . 

The second page of the form flashes the current 
CUSTODIAN ID, LOCATION, and DATE ASSIGNED fields transmitted 
from the first page. These flashing fields cannot be edited 
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which prevents interference of data entered on page one. The 
final def au It entries are the first set of hi stor i cal data 
fields, CUST0DIAN1, L0CATI0N1 , and ASSIGN DATE1 . These are 
filled with the initial data upon creation of the record, 
c. View and Report design 

The ini ti al appl i cati on desi gn prototype consi sted 
of the following four reports: Property Custody Log, Minor 

Property Inventory, Plant Property Inventory, and the Property 
History. A final review of the PMS prototype before system 
implementation resulted in the request for two additional 
reports, the Property Disposal Record and the Property 
Location report. A dBASE view file was designed for each 
report. The view is a representati on of a relation using only 
the fields required for the views intended use. Tables 7 and 
8, Appendix B, detail the views and reports. 

The basic report designs were drawn up on paper 
during interviews with the users. Report titles, field 
locations, groupings, and calculations were decided on at this 
time. The reports were designed to be printed on 11 by 14 7/8 
inch paper which is consistent with reports generated by the 
original FMIS. As a maintenance enhancement, a major design 
goal was for the PMS reports to be similar in format to other 
system application reports. dBASE IV offers three general 
report layouts: the column layout, the form layout, and the 
mailmerge layout. The column layout format which includes 
subtotals and totals was used in all PMS reports. 
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E. PHASE V, IMPLEMENTATION 
1. System Programming 

Constructing the system in accordance with the design 
is the fundamental task of implementation. The control center 
incorporated by dBASE IV provides most of the tools required 
for building the various parts of the system. A code 
generator automatically writes program code to perform each 
system function constructed in the control center. The 
database, views, screen form, and reports in the Property 
Management System must all be created first, then the system 
can be integrated into the overall FMIS application program. 
Several special functions and procedures that needed to be 
coded manually are provided in Appendix C and explained below. 

The SRCHTGNR procedure is called by the EDIT/VIEW 
RECORD property menu option. It searches the PROPERTY 
database for the record cor respond i ng to the entered tag 
number and returns either that record or a message stating 
that the tag number doesn’t exist. 

PROPOPEN is a procedure that opens the PERSONNE and 
PROPERTY databases for linked use in the PROPERTY form. This 
is required to allow simultaneous access of information in 
both data files. IDCODE is used as a common field between 
files. 

The IsCust function validates the input custodian ID 
with the PERSONNE file. If valid it returns the corresponding 
last and first name, if not it produces an error message. 
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RECRENDX is a procedure to rebuild index files in case 
they become corrupted by a power failure or some other 
problem . 

The final special procedure, RESTORE, restores the 
current system drive with a previous backup of all system 
databases. All of these procedures and functions are 
contained under one overall procedure file named ACCTPROC.PRG 
which is opened when the FMIS program is executed. 

The dBASE IV application generator provided the tools 
to make the necessary changes to the original FMIS program and 
integrate the new PMS module. The sign-on banner was also 
updated to reflect the new version of the program. Program 
documentation (Appendix D) was generated as a concluding 
programming task. Accurate documentation is vital to provide 
an effective reference for future program maintenance. 

2. Testing 

Each section of the system was thoroughly checked for 
correct function using a black box type testing procedure. 
Black box testing is a testing method where inputs are 
provided to the system with subsequent checking of the outputs 
to ensure that the systems overall function is as expected. 
This testing method does not concern itself with internal 
functions, rather it checks the correctness of the system as 
a whole. The PMS system was tested alone and as part of the 
FMIS 2.0. Approximately 20 various test records were entered 
into the system for testing. Minor errors were detected and 
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corrected in the entry form and in some of the reports. One 
of the entry form errors resulted in the necessity of the 
PROPOPEN procedure discussed in the previous section. A group 
test was the last stage to see if there were any final 
functional problems that the programmer may have overlooked. 
This test went smoothly and any additional changes were agreed 
to be made as corrective maintenance after implementation. 

3. Installation 

The final stage of development is Installation. There 
are two main methods to install a new system. One method is 
to abandon the old system and start using the new one all at 
once. The second method, and the one to be used in installing 
FMIS 2.0, is to run the two systems in parallel. Running the 
two systems in parallel will allow time for undetected errors 
in the new system to surface and be corrected before total 
conversion. This is the preferred method since the original 
reliable system will still be in place in case of any 
unexpected problems. The planned time span for parallel 
operation is 9-30 September, 1991. This is an ideal schedule 
because the planned conversion will coincide with the start of 
the new fiscal year ( FY 92). 
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IV. CONCLUSIONS 



The initial FMIS has proven itself in actual use through 
the current fiscal year. FMIS 2.0, a software maintenance 
enhancement, was the central topic of this thesis. It 
consisted of the successful development of a Property 
Management module and integration of this module into the 
original system . Minor perf ecti ve mai ntenance was also 
performed on the original system, consisting mainly of report 
reformatt i ng . FMIS 2.0 is on schedule to replace the original 
system at the start of fiscal year 92. 

The changes incorporated into FMIS 2.0 originated from 
user requests over the first six months of initial system use. 
As discussed in section II, software maintenance is an ongoing 
task throughout system life. Additional desired changes to 
the program surface constantly, often discovered while 
performing other maintenance functions. Many of these new 
requirements and corrections could be incorporated as material 
for future thesis work. Specific ideas for follow on work are 
discussed in the following paragraphs. 

Within each module in the current system archi tecture , the 
same screen form is utilized for both entering and editing 
records. The development and integration of separate edit 
forms for each database would alleviate screen congestion 
during the editing function and also protect permanent data 
from erroneous changes. 
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Midway through development of FMIS 2.0 the A.S. department 
initiated a small mi crocomputer Local Area Network (LAN). 
Currently there are only two stations connected, one in 1-231 
and one in I-231A. The availability of personnel data on this 
new network brings forth the need for development of database 
security. As the number of stations expand, access to certain 
system files must be restricted to authorized users. 

Further perfective maintenance can be performed to 
discover and reduce any remaining anomalies in the system. 
The goal would be to raise the system to the fourth normal 
form or higher. 

A final suggestion would be to explore the feasibility and 
benefits of performing an adaptive maintenance change. 
Specifically, changing the system from dBASE IV to a new soft- 
ware development platform. Alternate database development 
packages may offer desired features not available in the 
current system. 
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APPENDIX A 



REQUIREMENTS DOCUMENTATION 
A. TABLE 1: OBJECT DIAGRAM 



Number 

Document- number 

Type 

Code 

Pr i or-tag 
Personnel-ID 
PERSONNEL 
Model 

Acqui si ti on 

Date-assigned 

Seri al -number 

Di sposal 

Disposal-date 

Location 

Name 

Manuf acturer 

Inventory 

Price 

Historical -custodian.... 

MV 

Hi stori cal -location.,.. 

MV 

Hi stori cal -assignment.,., 

MV 

Historical -transf er.,., 

MV 

PROPERTY 



MV - Multivalued 
PERSONNEL 



Object Property 
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B. TABLE 2: OBJECT DEFINITION 



PROPERTY OBJECT 

Number; Property-tag-number 

Document-number ; Suppl y-document-number 

Type; Property-type 

Code; Property-ADP-code 

Prior-tag; Pr i or-tag-number 

Personnel-ID; Personnel-ID-code 

PERSONNEL; PERSONNEL object; SUBSET [First-name, 
Last-name] 

Model; Model-number 

Acquisition; Acquisition-date 

Date- ass i gned ; Property-assi gnment-date 

Seri al -number ; Property-ser i a 1 -number 

Disposal; Di sposal -status 

Di sposal -date ; Di sposal -date 

Location; Property- 1 ocati on 

Name; Property-name 

Manuf acturer ; Manuf acturer-name 

Inventory; Last- i nventory-date 

Price; Property-cost 

H i stor i cal -custodi an ; Past-personnel -IDs ; MV 
Historical-location; Past-property-locations; MV 
Historical-assignment; Past-property-assi gn-dates ; MV 
Historical-transfer ; Past-transf er-dates ; MV 
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c. 



TABLE 3: PROPERTY DOMAIN DEFINITIONS 



Acqui si ti on-date : 

Text 5, mask MM/YY 

where MM is month, YY is year 
Month and year property item received by supply 

Di sposal -date : 

Date Format (MM/DD/YY) 

Date property disposed of 

Disposal -status: 

Text 1 , X 

where X is either Y for yes, or N for no 
Indicates whether property has been disposed of 

Last- inventory- date: 

Date Format 

Date that last inventory was conducted on property item 

Manuf acturer-name : 

Text 10 

Name of property item manufacturer 

Model -number : 

Text 1 1 

Model number of item (number may include characters) 

Past- personnel -IDs : 

Text 2 

Unique personnel identification code of person having 
had custody of property item in the past 

Pas t- property- ass i gn- dates : 

Date Format 

Date property item originally assigned to a past 
custod i an 

Past- property- 1 ocat i ons : 

Text 5, mask B-NNN 

where B indicates Building, NNN is room number 
Location property items previously assigned 

Past- transfer-dates : 

Date Format 

Date item transferred from past custodian 

Personnel -ID-code 
Text 2 

Unique personnel identification code 
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TABLE 3 continued 



PERSONNEL (separate object) 

First-name, Text 10 
Last-name, Text 15 

Name of Property custodian from PERSONNEL file 

Pr i or- tag- number 
Text 9 

Previous identification assigned to item if any 

Property-ADP-code 
Numeric, mask X 

where X is either 0 (non-ADP), or 1-5 
Code number to classify item to an ADP category 

Property-assi gnment-date 
Date format 

Date property item assigned to current custodian 



Property-cost 

Numeric 12, mask N , NNN , NNN . NN 
Actual cost of property item 

Property- 1 ocat i on 

Text 5, mask B-NNN 

where B indicates Building, NNN is room number 
Current location of assigned property item 



Property-name 
Text 20 

Generic name of property Item, i,e. computer printer 



Property- tag- number 
Numeric 6 

Unique AS dept tag number 

Property-type 

Text 1 , mask M 

where M is either 
Identifies item as either 

Property-ser i a 1 -number 
Text 15 

Unique number assigned to 



assigned to property item 



M (Minor) or P (Plant) 
minor or plant property 



item by manufacturer 



Suppl y- document- number 
Text 9 

Document number assigned to purchase order of item 
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D. TABLE 4: PROPERTY UPDATE MECHANISMS 



I. Add new PROPERTY data 

A. Inputs 

* Supply information from purchase order 

* List of available tag numbers 

* Information of prospective custodian and location 

B. Outputs 

* New PROPERTY object instance in database 

* New screen for next record entry 

C. Processing notes 

* Tag number must be unique 

* Prospective custodian must exist in PERSONNEL file 

* Property-cost is actual price paid 

D. Volume 

* Will vary. Approximately 200 per FY 

E. Frequency 

* Daily 

II. Edit data in PROPERTY 

A. Inputs 

* Tag number of item to be edited 

* List of information to be changed 

* PROPERTY object instance from database 

B. Outputs 

* Modified object instance to database 

C. Processing notes 

* Tag number must be valid to enter request 

* Invalid tag number results in opportunity to try 
again 

* Tag number is constant, do not change 

D. Frequency 

* Semi -weekly 

III. Delete PROPERTY data 

A. Inputs 

* Tag number of record to delete 

* Information to confirm correct record for deletion 

B. Outputs 

* Screen message of record deleted 

C. Processing notes 

* Record for deletion will be retrieved through the 
Edit process 

* Records should rarely be deleted since historical 
property item data is required to be maintained in 
data file. Delete only erroneous records. 

D. Frequency 

* Bi-weekly 
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E. TABLE 5: PROPERTY DISPLAY MECHANISMS 



I. Query on PROPERTY 

A. Output description 

* Form showing all data for a property item 

B. Source data 

* PROPERTY and PERSONNEL objects 

* Tag Number keyed by clerk 

C. Processing notes 

* Used by AS department administrative workers 

D. Volume 

* 25 per week 

E. Frequency 

* Daily 

II. Minor Property Inventory Report 

A. Output description 

* Report of Minor property assigned AS tag numbers 

B. Source data 

* PROPERTY and PERSONNEL objects 

C. Processing notes 

* Report to be chosen from menu selection 

* Ordered by tag number 

D. Frequency 

* Bi-weekly 

III. Plant Property Inventory Report 
A. Output description 

* Report of Plant property assigned AS tag numbers 
B-D. Same as II 

IV. Property Custody Log Report 
A. Output description 

* Report of property items assigned to custodian 
grouped and sorted by custodian 

B-D. Same as II 

V. Property Disposal Report 

A. Output description 

* Report of disposed property, grouped by ADP code 

B. Source data 

* PROPERTY object 
C-D. Same as II 

VI. Property Location Report 
A. Output description 

* Report of tagged property grouped by room location 
B-D. Same as II 
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APPENDIX B 



DATA DICTIONARY 



A. TABLE 6 


: PROPERTY. DBF 


DATA ELEMENTS 


ELEMENT 


TYPE 


WIDTH 


DESCRIPTION 


DOCNR 


CHAR 


9 


Document number assigned. 


TAGNR 


NUM 


6 


AS tag number assigned to 
property item. 


PROPTYPE 


CHAR 


1 


Minor or Plant property 
identifier (M or P). 


ADPCODE 


NUM 


1 


ADP property classification. 


PRIORTAGNR 


CHAR 


9 


Previous tag number. 


IDCODE 


CHAR 


2 


Personnel identification code 


MODELNR 


CHAR 


1 1 


Manuf acturers model number. 


ACQDATE 


CHAR 


5 


MM/YY property received by 
suppl y . 


ASSIGNDATE 


DATE 


8 


Date property assigned to 
current custodian. 


SERIALNR 


CHAR 


1 5 


Property item serial number. 


DISPOSED 


LOGICAL 


1 


Indicates whether item is 
disposed of. 


DISPDATE 


DATE 


8 


Date of item disposal. 


LOCATION 


CHAR 


5 


Location of property item. 


REMARKS 


CHAR 


66 


Remarks . 


NAME 


CHAR 


20 


Generic name of property item 


DESC 


CHAR 


20 


Descriptive detail of item. 


MFG 


CHAR 


20 


Manufacturer name. 


INVDATE 


DATE 


8 


Date of latest inventory. 


ACTPR ICE 


NUM 


12 


Actual price paid for item. 
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TABLE 6: continued 



ELEMENT 


TYPE 


WIDTH 


DESCRIPTION 


CUST1 


CHAR 


2 


First person (ID) to have 
custodianship of property item 


CUST10 


CHAR 


2 


Tenth person (ID) to have 
custodianship of property item 


LOCATION 1 


CHAR 


5 


Location of item during first 
person assigned as custodian. 


L0CATI0N1 0 


CHAR 


5 


Location of item during tenth 
person assigned as custodian. 


RECVDATE 1 


DATE 


8 


Date item assigned to first 
custodi an . 


RECVDATE 1 0 


DATE 


8 


Date item assigned to tenth 
custodian . 


TRANSFER 1 


DATE 


8 


Date item transferred from 
first custodian. 


TRANSFER 1 0 


DATE 


8 


Date item transferred from 
tenth custodian. 



Note: CUST2 - CUST9, L0CATI0N2 - L0CATI0N9 , RECVDATE2- 

RECVDATE9 , and TRANSFER2 - TRANSFER9 field element 
descriptions omitted from table. 
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B. TABLE 7: 



PROPERTY MANAGEMENT SYSTEM VIEWS 



VIEW FILE 
PROPCUST . QBE 

PROPDI SP . QBE 
PROPH I ST . QBE 

PROPI NVM . QBE 

PROPINVP . QBE 

PROPLOCN . QBE 



DATA FILE USED 



DATA ELEMENTS 



PERSONNE . DBF 
PROPERTY. DBF 



LASTNAME 

IDCODE , TAGNR, LOCATION, 
NAME, DESC , MFG , MODELNR , 
SERIALNR, ACQDATE , ACTPRICE, 
INVDATE , ASSIGNDATE , REMARKS 



PROPERTY. DBF 



ADPCODE , TAGNR, PRIORT AGNR , 
DISPDATE, NAME, DESC, MFG, 
MODELNR, SERIALNR, ACTPRICE, 
REMARKS 



PROPERTY. DBF 



LOCATION1 -LOCATION1 0 , 
TRANSFER 1 -TRANSFER 1 0 , 
RECVDATE1 -RECVDATE1 0 , CUST1 
CUST10, TAGNR, NAME, DESC, 
MFG, MODELNR, SERIALNR 



PERSONNE . DBF 
PROPERTY. DBF 



LASTNAME 

TAGNR, LOCATION, NAME, 
PROPTYPE, DESC, MFG, 
MODELNR, SERIALNR, IDCODE, 
ACTPRICE, INVDATE 



PERSONNE. DBF 
PROPERTY. DBF 



LASTNAME 

TAGNR, LOCATION, NAME, 
PROPTYPE, DESC, MFG, 
MODELNR, SERIALNR, IDCODE, 
ACTPRICE, INVDATE 



PERSONNE. DBF 
PROPERTY. DBF 



LASTNAME 

IDCODE, TAGNR, LOCATION, 
NAME, DESC, MFG, MODELNR, 
SERIALNR, ACQDATE, ACTPRICE, 
INVDATE, ASSIGNDATE, REMARKS 
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c. 



TABLE 8: PMS PROPERTY REPORTS 



RE PORT FILE 
PROPCUST . FRG 

PROPDISP. FRG 

PROPHIST . FRG 



PROPINVM. FRG 
PROPINVP. FRG 
PROPLOCN. FRG 



VIEW FIL E DESCRIPTION 

PROPCUST. QBE PROPERTY CUSTODY LOG: shows 

all property items assigned 
to each custodian. Cost 
subtotals provided for each 
custodi an . 



PROPDISP. QBE 



PROPHIST. QBE 



PROPINVM. QBE 



PROPINVP. QBE 



PROPLOCN. QBE 



PROPERTY DISPOSAL REPORT: 
shows all disposed property 
grouped by ADP code class- 
ification. Subtotal for 
each disposed ADP type. 

PROPERTY CUSTODY HISTORY 
REPORT: all property in tag 
number sequence showing 
historical custodian, 
location, and property 
assignment date information. 

MINOR PROPERTY INVENTORY 
REPORT : tag number sequence 
of all minor property 
location and custodian 
(except disposed property). 

PLANT PROPERTY INVENTORY 
REPORT : tag number sequence 
of all plant property 
location and custodian 
(except disposed property). 

PROPERTY LOCATION REPORT: 
property items grouped in 
location sequence with sub- 
totals for each location. 
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APPENDIX C 



FMIS 2.0 CUSTOM PROCEDURES IN ACCTPROC.PRG 
A. RECRENDX 



* 






* 

* 

* 

* 

* 

* 

* 

* 

* 

* 



Procedure: RECRENDX 

— for re-indexing databases. 

Uses: ACCTS . DBF , DACCTS . DBF , PERSONNE . DBF 

LABOR 1 . DBF , PROPERTY . DBF , SUPPLY. DBF 
TRAVEL. DBF, TEMPLAB . DBF 



MDX files: ACCTS. MDX , DACCTS. MDX, PERSONNE. MDX 
LABOR1 . MDX , PROPERTY . MDX , SUPPLY. MDX 
TRAVEL. MDX, TEMPLAB. MDX 



*! -This procedure updated to include Property objects for 
*! FMIS version 2.0, by T. Ditri. 



PROCEDURE RECRENDX 

SET TALK ON && Show progress 

USE accts 

REINDEX 

USE daccts 

REINDEX 

USE personne 

REINDEX 

USE laborl 

REINDEX 

USE supply 

REINDEX 

USE travel 

REINDEX 

USE templab 

REINDEX 

USE property 

REINDEX 

SET TALK OFF && Suppress progress messages 
RETURN 
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B. RESTORE 



| ^ ^ ^ ^ ^ ^ N^r ^ ^ ^ ^ ^ ^ ^ \^ ^ ^ ^ ^ ^ ^ ^ ^ ,^. ^ ^ ^ ^ s^ ^ ^ v^ ^ 



* ! 


Procedure : 


RESTORE 






* ! 


- 


-Procedure for restoring backed-up dbase files 


* ! 


Uses : 


ACCTS. DBF, 


DACCTS. DBF, 


PERSONNE. DBF 


* ! 




LABOR 1 . DBF , 


PROPERTY. DBF, 


SUPPLY. DBF 


* ! 
* ! 
* ! 




TRAVEL. DBF, 


TEMPLAB. DBF 




MDX files: 


ACCTS. MDX, 


DACCTS. MDX, 


PERSONNE. MDX 


* ! 




LABOR 1 .MDX, 


PROPERTY. MDX , 


SUPPLY. MDX 


* [ 
* i 




TRAVEL. MDX, 


TEMPLAB. MDX 




* ! 


-This procedure updated 


to include Property objects for 


* ! 


FMIS version 2.0, by T 


. Di tri . 








PROCEDURE restore 



SET TALK ON && Show progress 
SET SAFETY OFF 
USE accts 



ZAP 

APPEND FROM a:\accts 

REINDEX 

USE daccts 

ZAP 



APPEND FROM a:\daccts 



REINDEX 

USE personne 

ZAP 

APPEND FROM a: 
REINDEX 
USE laborl 
ZAP 

APPEND FROM a: 
REINDEX 
USE supply 
ZAP 

APPEND FROM a: 
REINDEX 
USE travel 
ZAP 

APPEND FROM a: 
REINDEX 



\personne 



\ 1 abor 1 



\suppl y 



\travel 



USE templab 
ZAP 

APPEND FROM a:\templab 
REINDEX 
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USE property 
ZAP 

APPEND FROM a:\property 
REINDEX 

SET TALK OFF && Suppress progress messages 
RETURN 



C. SRCHTGNR 



* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 



******* * ************* * ** *** ************* ***** * ***** * ****** * 
Procedure: SRCHTGNR 

--validates tag number and retrieves record 
Calls: PROPERTY. FMT 
Uses: PROPERTY. DBF 

MDX files: PROPERTY. MDX 
Formats: PROPERTY. FMT 

This procedure is part of FMIS 2.0, by T. Ditri 



PROCEDURE SRCHTGNR 

* Property database opened through embedded code in the 

* application program 

SET TALK OFF 
SET ESCAPE OFF 
SET STATUS OFF 
SET SCOREBOARD OFF 
SET NEAR ON 
searching = . T. 

DO WHILE searching 
CLEAR 

memtag = 0 

@10,2 SAY "Enter Item Tag Number to retrieve: " GET; 
memtag 

READ 

* If nothing entered, retrieve first record for 

* browsing. 

IF memtag = 0 

SET FORMAT TO property 
EDIT NOAPPEND 
CLOSE FORMAT 
Searching = .F. 

1 oop 

ENDIF 
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